COMMENT ⊗   VALID 00005 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002		FEATURES TO BE ADDED TO POINTY
C00005 00003		FUTURE OF POINTY 	- 	APRIL 6, 1978
C00010 00004		FUTURE OF POINTY - AUGUST 1, 1978
C00011 00005	∂29-Jul-79  1648	MSM  
C00014 ENDMK
C⊗;
	FEATURES TO BE ADDED TO POINTY


			MAJOR
1)	MACROS
*	a)	macro record
*	b)	parser changes
*	c)	throw into input stream
*	d)	macro definition
2)	SIMULATION OF ARM MOTION WHEN ELF UNAVAILABLE
3)	IMPLICIT ARGUMENTS FOR EXPRESSIONS
4)*	DIRECT EXECUTION OF INSTRUCTIONS FROM SOURCE FILE
5)	DIMENSION CHECKING
6)	SAVE CONTEXT OF THE WORLD ON THE DISK FILE IN CASE USER CRASHES
	SYSTEM OR FOULS UP
7)*	MULTI-SEGMENT MOVES
8)*	FORCE SENSING
9)*	CONTROL STATEMENTS AND BLOCK STRUCTURE
10)	MACRO LIBRARY
11)	INTERNAL FORM OF FILE STORAGE FOR FAST I/0 without going through parser.
12)*	FUNCTION EXPRESSIONS WITHOUT PUTTING SOURCE TEXT THROUGH THE SCANNER
13)	DISK COPY OF FILE FOR IO
14)	XCOORD,YCOORD,ZCOORD(VECTOR)← <scalar exp>
	POS(FRAME)← <rot exp>
	ROT(FRAME)← <rot exp>
15)	change to parser ignore __ in a variable.

			MINOR
1)*	PRINT OUT DEFAULT MOVES ON SCREEN
2)	READARM BEFORE MOVEZ, MOVEX, ETC
3)	VALUE OF PI
4)	RADIAN FUNCTIONS
5)*	PRINT OUT DEVICE BLOCK WORDS CORRECTLY
6)*	PROMPT
7)	PAUSE
8)	PRINT VARIABLES ON BASIS OF LAST REFERRED TO
9)*	NODISPLAY, REDISPLAY, DISPLAY SCALARS
10)	CHANGE TO SYNTAX OF WRITE STATEMENT
		WRITE <var_LIST> INTO <file>
	*	WRITE INTO FILE
	*	WRITE ALL INTO FILE
	*	WRITE <var> INTO FILE
	*	WRITE <var>
		WRITE <var_list>
		WRITE SCALARS
		WRITE MACROS
11)	DELETE
12)	SAVE TEXT FOR PROCEDURE
	FUTURE OF POINTY 	- 	APRIL 6, 1978

	The next stage in the evolution of POINTY is the implementation
of macro facilities which enables the user to define his own
macros, with parameters if possible.  These macros will be simple
text substitution macros.  At this time we don't anticipate putting
in the full macro capabilities of SAIL.
After this is implemented, we will define a set of commonly used macros
that help the user to accomplish sequences of instructions like
LOCATE.

	The role of functions and subroutines have not been fully
defined yet; if implemented, they will not have any counterpart in
AL.  They will have the effect of variables proposed by the Ginis.
At the same time, they permit the user to accomplish things
not possible in macros (e.g. return values), 
and allow the storage of internal forms of expressions.  
The use of an internal form will be particularly useful
when we have swapping of modules.  The increase of data space is
offset by not having to call the parser as many times.
While we are doing this, we should consider
the ability to store information in an internal
form which makes file i/o faster to accomplish.  Such i/o of course can only be
to files written by POINTY which are not tampered with by the user.
This is contingent upon writing our own interpreter.
For a start, implementation of simple expression functions will be done to
evaluate the problems that crop up.


	The implementation of multi-segment moves, force compliance and
force sensing appears to be worthwhile, especially if we want to use 
POINTY as a means of trying out and debugging AL statements.  Multi-segment
moves should be implemented first, and they should take into account
via points, approach and deproach points, in addition to doing
several simple move statements consecutively.

	The treatment of block and control structure is next.
At what level should we execute instructions?  Should they be
done in terms of simple statements, or do we only strip off the
outermost BEGIN-END tokens?  In the case of inner blocks, do we
parse the whole block, or parse it statement by statement?
How will this affect IF..THEN..ELSE and WHILE...DO.. and a possible 
DO ... UNTIL ... statment?
Maybe we should restrict control statements to only simple statements.
The introduction of the control statements means expanding the
expression evaluator to handle boolean expressions in addition to
arithmetic expressions.
How can we handle COBEGIN-COEND statements?

	Other features we might want are the PAUSE and
PROMPT commands.  The PROMPT command seems particularly relevant
for the case where source programs are input from disk files.


ULTIMATE AMBITION -
	POINTY reads in an AL source file and executes it statement
by statement, and after each successful execution copies it out on a disk
file.  When there are errors, the user is given the option of
hot editing the statement which POINTY will execute and if
successful will write into a disk file.  At the end of the POINTY
session there will be a correct running AL program which
does not cause grief to the AL compiler.
	FUTURE OF POINTY - AUGUST 1, 1978

	ALAID INTERFACE
	VISION INTERFACE
	WHATEVER PLANNING PROGRAMS INTERFACE
	STOP IMPLEMENTING MORE AL FUNCTIONS INTO POINTY
∂29-Jul-79  1648	MSM  
To:   MLG, GG
Things to think about................

RECORDS:	implementation of records
HELP MESSAGES:	possiblity of treelike system of explaining options
ERROR MESSAGES:	other possibilities
INTERFACE TO RUNNING AL PROGRAM:
		redesigning the POINTY system without the display
		but with the possibility of making a module on the
		10 that will interface to other SAIL programs
UNITS:		in the runtime system
DIMENSIONS:	in the 10 part
INTERNAL FORM:	storage of info in some internal form that bypasses the
		scanner since only the program can write or read it
		for fast saving and initializing.
STATISTICS COLLECTION:
		for particular variables
AL STATEMENTS TO BE IMPLEMENTED:
		Full move statements with clauses
			C-M, deproach etc
		CASE statement
		SIGNAL, WAIT, PROMPT
FILE I/O: 	when we have the disk online
PROCEDURES:	saving them in text form and keeping tabs on the
		global variables inside them to ensure validity
COMPONENTS OF DATA STRUCTURES:
		e.g. POS(fr)←<vect>
		ORIENT(fr)←<rot>
		ZCOORD(vect)←<scalar>
		XCOORD(fr)←<scalar>
FULL AFFIXMENTS:
		including the BY variable
NEW form of move statement that treats the arm and hand together
	e.g.
	MOVE [barm,bhand] TO
		[f1,3],[f2,3],[f3,3.8],[f3,0];

STRUCTURED DATA TYPE?
	somehow define combination of frames and hands as a data type
	and somehow define the destinations as those data types too.
	(will have to think a bit more about this).